home *** CD-ROM | disk | FTP | other *** search
/ The X-Philes (2nd Revision) / The X-Philes Number 1 (1995).iso / xphiles / hp48_2 / svc < prev    next >
Internet Message Format  |  1995-03-31  |  5KB
  1. From helens!shelby!rutgers!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekfdi!videovax!bill Thu Jun 14 13:36:24 PDT 1990
  2. Status: RO
  3.  
  4. Article 1901 of comp.sys.handhelds:
  5. Path: helens!shelby!rutgers!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekfdi!videovax!bill
  6. >From: bill@videovax.tv.tek.com (William K. McFadden)
  7. Newsgroups: comp.sys.handhelds
  8. Subject: Re: Assorted HP48 questions
  9. Message-ID: <5850@videovax.tv.tek.com>
  10. Date: 13 Jun 90 19:24:58 GMT
  11. References: <8815@hacgate.UUCP>
  12. Reply-To: bill@videovax.tv.tek.com (William K. McFadden)
  13. Organization: Tektronix TV Measurement Systems, Beaverton OR
  14. Lines: 86
  15.  
  16. In article <8815@hacgate.UUCP> ferris@tcville.HAC.COM () writes:
  17. >I have the distinct impression, and I have a sinking feeling that it is
  18. >because it is correct, that for an object to be globally accessable,
  19. >it must reside in the HOME directory.  If this is indeed true, it is
  20. >unfortunate there isn't a path variable the user can create.
  21.  
  22. Some time ago, jc@atcmp.nl (Jan Christiaan van Winkel) posted a method of
  23. getting around this.  What you do is create a { HOME LIB } directory and use a
  24. program called 'SVC' (service call) to call it.  The SVC program resides in
  25. your home directory.  It is true that the LIB directory gets full of lots of
  26. programs, but I think it is better than having them cluttering the HOME
  27. directory.  Anyway, here is the program (with some improvements I've made):
  28.  
  29. SVC  (Bytes #1C7Fh 49)
  30.  
  31. << PATH            ;get current path
  32.    SWAP            ;get program name in level 1
  33.    { HOME LIB } EVAL    ;go to LIB directory (HOME LIB by itself also works,
  34.             ;but bombs in debug mode, i.e., single stepping)
  35.    RCL            ;recall library routine to stack
  36.    SWAP EVAL        ;go back to original directory
  37.    EVAL            ;execute library routine
  38. >>
  39.  
  40. To use this routine from a program, you put the library routine's arguments on
  41. the stack, followed by the name of the routine in single quotes.  Then call
  42. SVC.  For example:
  43.  
  44. 6.133990
  45. 'DOW'
  46. SVC
  47.  
  48. Which returns "Wednesday" to the stack.  Notice also that SVC returns to the
  49. original directory before executing the library routine.  Hence it will use
  50. that directory's environment.
  51.  
  52. >The situation
  53. >in which this creates the most trouble is having a program in a lower
  54. >directory assigned to a key.  When in another directory and in USER mode,
  55. >pressing that key places on the stack the name of the program, which EVALs
  56. >to only itself.
  57.  
  58. Instead of assigning 'DOW' to a key, you would assign << 'DOW' SVC >> to the
  59. key, making it globally accessible.  However, this forces you to put DOW in the
  60. LIB directory.  If this is not desirable you could instead assign to the key
  61. << PATH HOME DIR1 DIR2 .. DIRn DOW EVAL >>, where HOME .. DIRn is the path to
  62. the program (DOW in this example).  If you wanted the program to reside in the
  63. other directory but execute in the current one, you could use << PATH HOME
  64. DIR1 DIR2 .. DIRn 'DOW' RCL SWAP EVAL EVAL >>.  In effect, you would assign a
  65. custom version of the SVC program to the key.  These ideas could also be
  66. extended to control alarms that execute a program in another directory but
  67. leave the calculator in the original directory when finished.
  68.  
  69. >Is there a _system provided_ way to make a key assignment
  70. >inactive when not in the directory that the object assigned to that key
  71. >resides?  What this boils down to is having different key assignments for
  72. >each directory. Is this possible?
  73.  
  74. Other than using menu keys, I don't know of a way to unassign a key when you
  75. leave the directory.  I suppose you could use TYPE or IFERR to detect the
  76. existance of a program and evaluate it if it's there or execute the default
  77. function if it isn't.  For example, << IFERR 'DOW' RCL EVAL THEN DROP SIN
  78. END >> would execute DOW if it exists, otherwise would execute SIN (or whatever
  79. the default function is for that key).
  80.  
  81. >I have noticed when using the BYTES command, that 100% of the time, the
  82. >number of bytes returned is _lower_ than the amount specified either in
  83. >the manual or by other people when keying their programs.  The checksums
  84. >match, but the byte count is lower. I have revision D of the ROMs, and
  85. >I've been wondering if HP came up with a different way to store objects
  86. >that is less space consuming. Now I certainly won't pass up more
  87. >efficient data compactions!
  88.  
  89. This, too, puzzled me at first.  I discovered you can get two different answers
  90. depending on what you supply to the BYTES command.  For example, 'SVC' BYTES
  91. returns #1C7Fh 49, but 'SVC' RCL BYTES returns #1C7Fh 41.5.  The difference is
  92. the first call to BYTES included the program name in its count, and the second
  93. didn't.  I have seen programs posted to the net both ways, but I believe the
  94. HP48 I/O firmware uses the first version.
  95.  
  96. Happy programming!
  97. -- 
  98. Bill McFadden    Tektronix, Inc.  P.O. Box 500  MS 58-639  Beaverton, OR  97077
  99. bill@videovax.tv.tek.com,     {hplabs,uw-beaver,decvax}!tektronix!videovax!bill
  100. Phone: (503) 627-6920       "The biggest difference between developing a missle
  101. component and a toy is the 'cost constraint.'" -- John Anderson, Engineer, TI
  102.  
  103.  
  104.